Computer workstations provide system users with powerful tools to support a number of functions. An example of one of the more useful functions which workstations provide is the ability to perform highly detailed graphics simulations for a variety of applications. Graphics simulations are particularly useful for engineers and designers performing computer aided design (CAD) and computer aided management (CAM) tasks.
Modern workstations having graphics capabilities utilize "window" systems to accomplish graphics manipulations. An emerging standard for graphics window systems is the "X" window system developed at the Massachusetts Institute of Technology. The X window system is described in K. Akeley and T. Jermoluk "High-Performance Polygon Rendering", Computer Graphics, 239-246, (August 1988). Modern window systems in graphics workstations must provide high-performance, multiple windows yet maintain a high degree of user interactivity with the
workstation. Previously, software solutions for providing increased user interactivity with the window system have been implemented in graphics workstations. However, software solutions which increase user interactivity with the system tend to increase processor work time, thereby increasing the time in which graphics renderings to the screen in the workstation may be accomplished.
A primary function of window systems in graphics workstations is to provide the user with simultaneous access to multiple processes on the workstation. However, each of these processes provides an interface to the user through its own area onto the workstation display. The overall result is an increase in user productivity since the user can manage more than one task at a time with multiple windows. However, each process associated with a window views the workstation resources as if it were the sole owner. Thus, resources such as the processing unit, memory, peripherals and graphics hardware must be shared between these processes in a manner which prevents interprocess conflicts on the workstation.
Graphics workstations generally utilize graphics "pipelines" which interconnect the various components of the system. A graphics pipeline is a series of data processing elements which communicate graphics commands through the graphics system. Today, graphics pipelines and window systems are evolving to support multitasking workstations.
The typical graphics pipeline interconnects a "host" processor to the graphics system which provides the various graphics commands available to the system and which also interfaces with the user. The host processor is interfaced through the graphics pipeline to a "transform engine" which generally comprises a number of parallel floating point processors. The transform engine performs a multitude of system tasks including context management, matrix transformation calculations, light modeling and radiosity computations, and control of vector and polygon rendering hardware.
In graphics systems, some scheme must be implemented to "render" or draw graphics primitives to the system screen. A "graphics primitive" is a basic component of a graphics picture such as, for example, a polygon or vector. All graphics pictures are formed from combinations of these graphics primitives. Many schemes may be utilized to perform graphics primitives rendering. One such scheme is the "spline tessellation" scheme utilized in the TURBO SRX graphics systems provided by the Hewlett-Packard Company Graphics Technology Division, Fort Collins, Colo. Regardless of the type of graphics rendering scheme utilized by the graphics workstation, the transform engine is essential in managing graphics rendering.
A graphics "frame buffer" is interfaced further down the pipeline from the host processor and transform engine in the graphics window system. A "frame buffer" generally comprises a plurality of video random access memory (VRAM) computer chips which store information concerning pixel activation on the display corresponding to the particular graphics primitives which will be rendered to the screen. Generally, the frame buffer contains all of the data graphics information which will be written onto the windows, and stores this information until the graphics system is prepared to render this information to the workstation's screen. The frame buffer is generally dynamic and is periodically refreshed until the information stored on it is rendered to the screen. The host and frame buffer have associated bandwidths. The bandwidth is a measure of the rate of data flow over a data path.
In order to accelerate multiple processes in a graphics system, the graphics pipeline must be capable of handling multiple "contexts". A graphics context consists of the current set of attributes, matrix stack, light sources, shading control, spline basis matrices, and other hardware state information. Previous graphics systems were generally only able to support a single graphics context at a time and required the host's software to perform all of the context switching. In these systems, software context switching requires the host to store the context for each active process in virtual memory, write the context to the device when the process is active, and read the context back in the system. This process is extremely time consuming and inefficient, and does not adequately support high level graphics operations in the graphics system.
Several problems exist in state of the art graphics window systems utilizing graphics pipelines. A significant known difficulty arises when multiple contexts must be switched through the pipeline. Whenever a window context must be changed or "switched" through the graphics pipeline, the pipeline must be "flushed". Flushing requires that the pipeline be emptied of data to determine if all of the data corresponding to the previous context has passed through the pipeline to the frame buffer.
There are problems attendant in this method of context switching. Since all the data must be emptied from the pipeline to determine if the previous context has passed through to the frame buffer before the next context can be input to the pipeline from the host, severe limitations in rendering graphics primitives to the screen in a timely fashion are introduced and the system is significantly slowed. Furthermore, host management of this kind of context switching greatly increases the host's overhead duties, thereby decreasing the host's efficiency and increasing host processor time dedicated to matters not associated with actively rendering data to the frame buffer. Thus, graphics pipeline flushing is an inadequate and inefficient method to accomplish context switching in modern window systems utilizing graphics pipelines.
Other timing problems exist in window systems utilizing graphics pipelines. All graphics pipelines experience pipeline "latency" which is defined as the time required for a single primitive to traverse the pipeline. A significant difficulty is encountered during context switching in graphics pipelines as a result of pipeline latency, since pipeline latency decreases the window system's responsiveness and user interactivity. Furthermore, complex primitives require significant processing time for rendering and therefore, force other primitives to back up in the pipeline until they are completely rendered to the screen.
Thus, window operations which theoretically should be interactive with the user oftentimes force the user to wait while graphics primitives are being rendered. Since graphics pipelines and graphics workstations are evolving to support more complex primitives and longer pipelines, pipeline latency and pipeline flushing now present prohibitive problems in the ongoing effort to increasing pipeline throughput and efficiency.
There is thus a long-felt need in the art for graphics pipeline architectures which eliminate the need for pipeline flushing and reduce pipeline latency. Additionally, there is a long-felt need in the art for pipeline graphics systems to support multiple context switching. Furthermore, a long-felt need in the art exists for graphics systems which support multiple contexts, yet reduce the need for complex host management and processor overhead. These needs have not heretofore been satisfied in the graphics window art by any current software implementations currently in use.